MeshProtos

Responses to a ChunkedPayload request

A notification message from the device to the client
To be used for important messages that should to be displayed to the user
in the form of push notifications or validation messages when saving
invalid configuration.

Compressed message payload

Shared constants between device and phone

Error codes for critical errors
The device might report these fault codes on the screen.
If you encounter a fault code, please post on the meshtastic.discourse.group
and we'll try to help.

(Formerly called SubPacket)
The payload portion fo a packet, this is the actual bytes that are sent
inside a radio packet (because from/to are broken out by the comms library)

Device metadata response

Enum for modules excluded from a device's configuration.
Each value represents a ModuleConfigType that can be toggled as excluded
by setting its corresponding bit in the `excluded_modules` bitmask field.

Individual File info for the device

Enum to indicate to clients whether this firmware is a special firmware build, like an event.
The first 16 values are reserved for non-event special firmwares, like the Smart Citizen use case.

Packets from the radio to the phone will appear on the fromRadio characteristic.
It will support READ and NOTIFY. When a new packet arrives the device will BLE notify?
It will sit in that descriptor until consumed by the phone,
at which point the next item in the FIFO will be populated.

Note: these enum names must EXACTLY match the string used in the device
bin/build-all.sh script.
Because they will be used to find firmware filenames in the android app for OTA updates.
To match the old style filenames, _ is converted to -, p is converted to .

A heartbeat message is sent to the node from the client to keep the connection alive.
This is currently only needed to keep serial connections alive, but can be used by any PhoneAPI.

The actual over-the-mesh message doing KeyVerification

Debug output from the device.
To minimize the size of records inside the device code, if a time/source/level is not set
on the message it is assumed to be a continuation of the previously sent message.
This allows the device code to use fixed maxlen 64 byte strings for messages,
and then extend as needed by emitting multiple records.

A packet envelope sent/received over the mesh
only payload_variant is sent in the payload portion of the LORA packet.
The other fields are either not sent at all, or sent in the special 16 byte LORA header.

This message will be proxied over the PhoneAPI for the client to deliver to the MQTT server

Unique local debugging info for this node
Note: we don't include position or the user info, because that will come in the
Sent to the phone in response to WantNodes.

A single edge in the mesh

Full info on edges for a single node

The bluetooth to device link:
Old BTLE protocol docs from TODO, merge in above and make real docs...
use protocol buffers, and NanoPB
messages from device to phone:
POSITION_UPDATE (..., time)
TEXT_RECEIVED(from, text, time)
OPAQUE_RECEIVED(from, payload, time) (for signal messages or other applications)
messages from phone to device:
SET_MYID(id, human readable long, human readable short) (send down the unique ID
string used for this node, a human readable string shown for that id, and a very
short human readable string suitable for oled screen) SEND_OPAQUE(dest, payload)
(for signal messages or other applications) SEND_TEXT(dest, text) Get all
nodes() (returns list of nodes, with full info, last time seen, loc, battery
level etc) SET_CONFIG (switches device to a new set of radio params and
preshared key, drops all existing nodes, force our node to rejoin this new group)
Full information about a node on the mesh

RemoteHardwarePins associated with a node

A GPS Position

Wrapper message for broken repeated oneof support

A message used in a traceroute

A Routing control Data packet handled by the routing module

Packets/commands to the radio will be written (reliably) to the toRadio characteristic.
Once the write completes the phone can assume it is handled.

Broadcast when a newly powered mesh node wants to find a node num it can use
Sent from the phone over bluetooth to set the user id for the owner of this node.
Also sent from nodes to each other when a new node signs on (so all clients can have this info)
The algorithm is as follows:
when a node starts up, it broadcasts their user and the normal flow is for all
other nodes to reply with their User as well (so the new node can build its nodedb)
If a node ever receives a User (not just the first broadcast) message where
the sender node number equals our node number, that indicates a collision has
occurred and the following steps should happen:
If the receiving node (that was already in the mesh)'s macaddr is LOWER than the
new User who just tried to sign in: it gets to keep its nodenum.
We send a broadcast message of OUR User (we use a broadcast so that the other node can
receive our message, considering we have the same id - it also serves to let
observers correct their nodedb) - this case is rare so it should be okay.
If any node receives a User where the macaddr is GTE than their local macaddr,
they have been vetoed and should pick a new random nodenum (filtering against
whatever it knows about the nodedb) and rebroadcast their User.
A few nodenums are reserved and will never be requested:
0xff - broadcast
0 through 3 - for future use

Waypoint message, used to share arbitrary locations across the mesh